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ABSTRACT 


It  is  common  to  have  a  hierarchical  communication  network  in  a  military  environ¬ 
ment.  If  we  consider  each  node  in  the  network  as  a  computer  site  then  we  have  a  hi¬ 
erarchical  computer  network.  In  a  hierarchical  computer  network,  because  the  need  of 
resource  sharing,  we  now  have  a  distributed  processing  system.  In  this  system  a  parent 
node  may  have  duplicate  records  of  all  its  children.  Any  update  of  a  record  has  to  be 
reflected  in  other  nodes  that  keep  the  duplicates.  We  need  a  concurrency  control 
mechanism  to  guarantee  the  integrity  of  the  distributed  database  and  the  seriali/ability 
of  concurrent  updates. 

This  paper  is  the  first  to  investigate  the  performance  in  hierarchical  networks  of  two 
widely-cited  concurrency  control  mechanisms,  locking  based  and  timestamp.  Various 
parameters  are  investigated  in  our  research:  number  of  nodes,  level  of'  network,  trans¬ 
action  arrival  rates,  and  message  transmission  speeds,  etc.  We  present  the  problem,  ex¬ 
plain  the  algorithms  used  in  our  simulation,  analyze  the  results,  and  discuss  the  findings. 
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I.  INTRODUCTION 


A.  BACKGROUND 

In  the  course  of  the  development  of' computer  and  communication  technology  se¬ 
veral  important  technical  achievements  have  been  introduced.  One  of  the  most  signif¬ 
icant  techniques  among  these  is  distributed  data  processing.  A  distributed  system 
consists  of  a  set  of  computers  located  in  different  sites  connected  by  a  communication 
network.  Programs  are  running  on  each  of  these  computers  and  the  programs  access 
local  or  remote  resources,  such  as  a  database. 

The  major  advantage  of  a  distributed  system  is  to  provide  low-cost  availability  of 
resources  of  the  system  by  localizing  accesses  and  providing  insulation  against  failures 
of  individual  components.  Since  many  users  can  be  concurrently  accessing  the  system, 
it  is  essential  that  a  distributed  system  should  provide  a  high  degree  of  concurrency. 
Due  to  the  requirement  of  data  sharing,  the  distributed  system  may  be  designed  with 
more  than  one  copy  of  the  same  data  in  different  locations.  This  partitioned  and  repli¬ 
cated  distributed  database  requires  synchronization  to  control  the  concurrent  multiple 
updates  and  maintain  its  consistency.  This  synchronization  is  called  the  concurrency 
control  algorithm. 

There  are  two  types  of  concurrency  control  approaches,  local  concurrent  control 
and  global  concurrency  control.  The  local  concurrent  control  mechanism  is  developed 
to  guarantee  that  a  step  of  a  transaction  is  executed  as  a  single  atomic  operation  at  an 
individual  node.  The  global  concurrency  control  mechanism  which  is  also  called  the 
update  algorithm,  controls  the  transactions  between  two  different  nodes  [Ref.  1].  Many 
algorithms  have  been  proposed  in  this  field  [Ref.  1]  [Ref.  2)  [Ref.  ?].  These  algorithms 
are  usually  complex  and  hard  to  understand.  However  most  of  the  work  on  concurrency 
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control  has  concentrated  on  the  development  of  new  algorithms,  and  not  as  much  at¬ 
tention  has  been  given  to  the  performance  evaluation  of  the  algorithms.  Also,  most 
performance  studies  are  done  in  general  network  structure  (Ref.  lj[Ref.  2]  [Ref.  4],  For 
military  settings,  the  line  of  authority  is  hierarchical,  therefore  military  systems  call  for 
hierarchical  computer  networks  in  a  distributed  system  environment.  System  managers 
or  designers  usually  like  to  investigate  performance  differences  and  sometimes  like  to 
dynamically  adapt  the  system  to  the  transaction  pattern.  Therefore,  it  is  important  to 
analyze  performance  differences  between  different  concurrency  control  algorithms  for 
hierarchical  networks.  This  research  is  to  report  the  performance  analysis  of  such  net¬ 
works. 

B.  DISTRIBUTED  DATABASE 

A  distributed  database  system  is  hosted  by  collection  of  geographically  separated 
computers  called  sites.  Each  sites  has  a  unique  identifier,  and  the  sites  are  interconnected 
by  a  communications  network.  Sites  communicate  with  each  other  by  means  of  messages 
sent  over  the  network.  Messages  may  be  arbitrarily  delayed  in  the  network,  but  it  is  as¬ 
sumed  that  all  messages  are  eventually  delivered. 

The  database  consists  of  an  unique  set  of  entities,  such  as  records  or  files,  that  are 
uniquely  named  and  that  serve  as  indivisible  units  of  access.  An  entity  is  realized  as  one 
or  more  data  objects,  each  of  which  is  uniquely  identified  by  an  (entity-name,  site- 
identifier]  pair. 

Replication  of  an  entity  occurs  if  it  is  represented  by  more  than  one  object.  Repli¬ 
cation  can  result  in  improved  performance  if  the  cost  of  storing  and  maintaining  (up¬ 
dating)  copies  is  less  than  the  cost  of  access.  Also  replication  can  improve  availability  in 
the  sense  that,  if  one  site  becomes  inaccessible,  then  users  may  be  able  to  access  the  data 
at  other  site.  In  our  model  it  is  assumed  that  each  entity  is  partially  replicated  which 
means  the  entities  are  not  replicated  at  all  nodes  but  replicated  at  some  nodes. 
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C.  CONSISTENCY  CONSTRAINTS 


We  would  like  to  keep  a  database  consistent.  However,  due  to  updating  activity,  the 
consistency  constraints  must  be  temporally  violated.  Two  levels  of  consistency  can  be 
defined  for  multiple  copies  of  data.  Strong  consistency  is  defined  as  the  condition  of 
having  all  copies  of  the  data  updated  at  the  same  time.  Strong  consistency  is  very  desir¬ 
able  becuse  all  copies  of  data  have  the  same  update  status  at  any  time,  but  this  always 
entails  a  considerable  delay  in  response  time  to  process  the  update  for  all  copies.  This 
is  because  the  update  of  all  copies  must  be  delayed  to  the  time  of  the  last  update  of 
system.  Weak  consistency  is  defined  as  the  condition  of  having  the  various  copies  of 
data  converge  to  the  same  update  status  over  time,  but  at  any  instant  of  time  some 
copies  may  lag  others  in  the  number  of  updates  processed.  Delays  in  general  will  be  re¬ 
duced  and  more  elficient  use  of  resources  is  possible.  In  a  weak  consistency  system  some 
copies  of  data  will  be  more  up-to-date  than  others  [Ref.  5).  Most  algorithms  are  devel¬ 
oped  under  weak  consistency  constraints  because  of  efficiency,  and  our  simulation  also 
follow  weak  consistency  constraints. 


D.  GENERAL  DEFINITIONS 

We  now  give  four  important  definitions  that  we  need  in  the  following  discussions. 

1.  Hierarchical  distributed  data  base  system:  A  system  with  the  database  dispersed 
throughout  a  number  of  nodes,  where  each  node  can  communicate  in  real  time  with 
one  or  more  subordinate  nodes,  but  with  only  one  superior  node  and  with  sulficient 
processing  power  at  each  node  to  manipulate  the  database. 

2.  Concurrency  control:  The  mechanism  of  maintaining  logical  data  consistency  in 
an  environment  of  contemion  among  multiple  update  sources. 

3.  Node:  Complete  computer  system  at  a  single  location. 

4.  Transaction:  Set  of  actions  which  transform  a  database  from  one  consistent  state 
into  another  consistent  state  [Ref.  5]. 
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E.  GENERAL  ASSUMPTIONS 


For  our  study  we  make  the  following  assumptions: 

1.  The  data  bases  are  partially  replicated  in  the  system,  which  is  more  practical  than 
completely  replicated  databases. 

2.  Although  update  transactions  may  add  or  delete  database  items,  we  consider  the 
total  number  of  data  in  database  to  be  constant,  that  is,  a  static  database. 

3.  All  nodes  have  local  concurrency  control.  We  are  not  concerned  with  local  con¬ 
currency  control  mechanism,  but  concentrate  on  the  global  concurrency  control 
algorithms. 

4.  There  is  a  communication  system  which  allows  any  node  to  communicate  with  any 
other  node. 

5.  No  failures  occur  in  the  system,  that  is.  the  communication  system  never  fails  to 
dehver  a  message. 

6.  All  transactions  which  are  used  lor  this  study  are  update  transactions. 

7.  There  is  no  multiprocessing  at  each  node.  The  transactions  which  arrive  at  certain 
nodes  are  served  serially.  Since  most  transactions  are  small,  the  schedule  algorithm 
in  each  node  should  not  have  a  noticeable  effect  on  the  response  time  and'  results 
obtained  with  the  model. 
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II.  CONCURRENCY  CONTROL  ALGORITHMS 


Concurrency  control  is  the  activity  of  coordinating  concurrent  accesses  to  a  data¬ 
base  in  a  multi-user  database  management  system.  Concurrency  control  permits  users 
to  access  a  database  in  a  multiprogrammed  fashion  while  preserving  the  illusion  that 
each  user  is  executing  alone  on  a  dedicated  system.  The  main  technical  difficulty  in 
achieving  this  goal  is  deconfliction.  Database  update  performed  by  one  user  must  not 
interfere  with  database  retrievals  and  updates  performed  by  another.  Although  many 
algorithms  have  been  proposed,  most  of  them  are  a  variation  of  two  basic  techniques, 
Two-I’hase  Locking  and  Time-Stamp  Ordering.  Alternatively  we  can  interpret  these  two 
technique  as  centralized  and  distributed  algorithms.  The  best  concurrency  control  al¬ 
gorithm  for  a  particular  application  depends  on  the  system  parameters.  We  will  discuss 
these  parameters  in  Chapter  3. 

A.  LOCKING-BASED  CONCURRENCY  CONTROL 

Objects  accessed  by  a  transaction  are  locked  in  order  to  ensure  their  inaccessibility 
to  other  transactions  while  the  database  is  temporarily  in  an  inconsistent  state.  There 
are  three  lock-releated  actions  on  objects: 

1.  (T.  Lock_X.  <  A  >  )  denotes  a  request  by  transaction  T  for  an  exclusive  lock  on  the 
object  <  A  >  .  The  request  is  granted  only  when  no  other  transaction  is  holding  a 
lock  of  any  type  on  object. 

2.  ( T.  Lock_S,  <A>  )  denotes  a  request  by  transaction  T  for  a  shared  lock  on  the 
object  <  A  > .  The  request  is  granted  only  when  no  transaction  is  holding  an  ex¬ 
clusive  lock  on  the  object. 

3.  (T.  Unlock  <A>  )  denotes  the  release  of  any  lock  by  transaction  T  on  the  object 
<  A  >  . 

A  transaction  is  said  to  be  well-formed  if  it  reads  an  object  only  while  it  is  holding 
a  shared  or  exclusive  lock  on  the  object  and  if  writes  an  object  only  while  it  is  holding 
an  exclusive  lock  on  the  object.  Tigure  1  illustrates  well-formed  transaction. 
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A  transaction  is  Two-Phase  if  it  docs  not  issue  a  lock  action  after  it  has  issued  an 
unlock  action.  The  first  phase  of  the  transaction,  called  the  growing  phase,  begins  with 
the  first  action  and  continues  up  to  the  first  unlock  action.  The  second  phase  of  the 
transaction,  called  the  shrinking  phase,  begins  with  the  first  unlock  action  and  continues 
through  the  last  action.  A  transaction  is  strong  two-phase  if  all  unlock  actions  are  issued 
at  the  very  end  of  the  transaction.  Figure  2  illustrates  a  typical  Two-Phase  locking 
action.  The  transaction  T1  locks  the  data  item  A,  and,  after  finishing  all  steps  of  the 
update,  it  unlocks  the  item  A.  IT  does  not  need  additional  lock  action  for  item  A. 

We  apply  the  Two-Phase  Locking  Algorithm  to  the  centralized  strategy  which  is  known 
Centralized  Locking  Algorithm  (CLA). 
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B.  CENTRALIZED  LOCKING  ALGORITHM  (CLA) 

l  or  the  centralized  locking  algorithm,  the  lock  manager  is  centralized  at  a  single 
node,  i.e.,  the  central  or  root  node.  It  manages  the  locks  of  all  data  elements  of  the  dis¬ 
tributed  database.  We  will  explain  the  steps  of  CLA. 

1.  An  update  transaction  T  arrives  at  node  X. 

2.  Node  X  requests  locks  from  the  central  node  for  all  items  referenced  bv  transaction 

r. 

3.  The  central  node  checks  all  the  request  locks.  If  all  can  be  granted,  then  a  granted 
message  is  sent  back  to  the  node  X.  If  some  items  are  already  locked,  then  the  re¬ 
quest  is  queued. 

4.  When  node  X  gets  a  "Grant"  message  for  transaction  T.  the  items  requested  by 
transaction  T  are  read  from  the  local  database  and  updated  values  are  computed. 

5.  A  "Perform  update  T"  message  is  sent  to  all  other  nodes,  informing  them  of  the 
update.  Node  X  updates  the  values  and  stored  in  its  local  database. 

6.  When  another  node  receives  its  "Perform  update  T'message,  it  performs  the  up¬ 
date. 

7.  When  the  central  node  receives  its  "Perform  update  T"  message,  it  releases  the  locks 
of  the  involved  items  and  then  performs  the  update  on  the  local  database.  Trans¬ 
actions  that  were  waiting  on  the  released  locks  are  notified,  and  can  continue  their 
locking  process  at  their  central  node. 

(End  of  CLA  algorithm) 
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C.  CONCURRENCY  CONTROL  ALGORITHMS  BASED  ON  TIME  STAMP 


Time-stamp  ordering  (T  O)  is  a  technique  whereby  a  serialization  order  is  selected 
a  priori  and  transaction  execution  is  forced  to  obey  this  order.  Each  transaction  is  as¬ 
signed  a  unique  time-stamp  by  the  time-stamp  manager  (TM).  There  also  is  a  time- 
stamp  associated  with  each  database  item  indicating  the  time  when  this  item  was 
updated.  Time-stamp  protocol  is  distributed  in  nature  since  all  nodes  which  share  the 
data  item  must  participate  in  the  decision  making.  So  here  we  see  the  distributed  voting 
algorithm  using  time-stamp  which  we  simulated. 

D.  DISTRIBUTED  VOTING  ALGORITHM  ( DVA) 

1.  When  transaction  T  arrives  at  a  node  X.  it  immediately  reads  the  items  and  time- 
stamp  of  desired  from  the  local  database.  We  use  Ts(  T,Di)^de  ,  to  denote  this. 

2.  Transaction  T  visits  the  next  node  (i.e.,  node  Y)  and  compare  the  time-stamp  for 
the  transaction  base  set  items  with  the  corresponding  time-stamps  in  the  local  da¬ 
tabase.  If  any  base  set  item  is  obsolete  (i.e..  Ts{T.Di).^,,  <  7  s(  Di)..Jc  v )  then  vote 

Reject"  and  send  the  "Reject"  message  to  originating  node.  The  transaction  will 
be  restarted.  If  each  base  item  is  current  (i.e.,  Ts^T.Di)^,,  >  Ts(Di)...A  )  then  vote 

Ok". 

3.  After  voting  all  the  nodes  which  have  the  base  item,  if  the  transaction  T  got  "Ok" 
at  all  nodes,  then  the  time-stamp  is  assigned  to  the  transaction  (i.e.,  7s(  1~) )  and  the 
"Accept"  message  with  Ts(T)  is  sent  to  all  nodes. 

4.  If  a  node  receives  an  "Accept"  message  and  if  Tsi  T)>  Ts{  T.Di),,,cr.  then  the  new 
values  are  stored  in  the  local  database  and  time-stamps  of  the  base  set  items  are 
changed.  Otherwise,  no  modification  is  performed,  since  the  values  are  obsolete. 

( End  of  DVA) 
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III.  SIMULATION  MODEL 

We  built  a  simulator  using  SIMSCRIPT  11.5  to  examine  the  algorithms  for  our 
study.  Each  simulator  has  an  update  transaction  generator  that  produce^  transactions. 
The  items  referenced  by  each  transaction  arc  selected  randomly.  The  simulator  then 
mimics  the  operation  of  the  hierarchical  system  as  it  produces  the  transactions.  Of 
course,  the  simulator  does  not  read  or  write  the  data  corresponding  to  a  transaction;  it 
only  mimics  this  by  requesting  the  necessary  1  (}  and  CPU  time  from  the  servers.  How¬ 
ever.  the  simulator  keeps  track  of  such  activities  as  granting  locks,  time-stamping  the 
item  values,  and  differed  transactions.  During  the  simulation,  statistics  such  as  average 
response  time  of  transactions  and  the  number  of  messages  are  collected. 

Several  model  parameters  are  used: 

1.  Mean  interarrival  time  of  update  at  each  node  tit).  We  assume  that  interarrival 
time  is  Poisson  distributed. 

2.  Mean  base  set  si/e  (Bs).  We  assume  that  the  number  of  items  referenced  by  an 
update  transaction  has  discrete  exponential  distribution. 

3.  Number  of  items  (M).  This  parameter  describes  the  total  number  of  data  items  in 
the  system. 

4.  The  number  of  nodes  (N). 

5.  The  network  transmission  time  (T).  In  order  to  simplify  the  simulation,  we  assume 
that  the  time  it  take  any  message  to  go  from  any  node  to  any  other  node  is  a  con¬ 
stant  T. 

6.  CPU  time  slice  (Cs).  The  CPU  time  slice  is  the  time  it  takes  any  CPU  server  to  do 
a  small  computation;  i.e.,  set  lock. 

7.  CPU  update  compute  time  (Cu).  Cu  is  the  compute  time  required  for  updating  one 
data  item.  In  other  words,  the  total  time  for  one  transaction  is  Cu  multiplied  bv 
Bs. 

8.  I  O  time  slice  (Id).  This  is  the  time  it  takes  to  read  or  write  a  data  item  from  the 
database  and  locks  or  time-stamps. 


The  following  parameter  values  are  common  to  most  of  the  previous  performance 
evaluation  studies  (Ref.  4]  [Ref.  6).  It  =  1  -  20  seconds.  Bs  =  2  -  10,  \  =  2  -  15  nodes. 
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T  =  0.1  seconds  M  =  100  -  2<'<)0.  Cs  =  O.uonol  seconds.  Cu  =  0.001  seconds,  and  Id 
=  0.025  seconds. 

A.  THE  PERFORMANCE  MEASURE 

There  are  many  variables  one  can  choose  to  evaluate  the  performance  of 

the  system.  In  this  study  we  will  consider  two  most  important  variables: 

1.  UPDATE  RESPONSE  TIME.  The  response  time  of  update  is  defined  as  the  dif¬ 
ference  between  the  finish  time  and  the  time  when  the  update  arrived  at  the  origi¬ 
nating  node.  The  average  response  time  of  update  transactions  will  be  investigated. 

2.  NUMBER  OF  MESSAGES.  Another  important  performance  variable  is  the 
number  of  messages  that  must  be  sent  per  update  transaction.  The  local  messages 
are  considered  internal  to  a  node  and  are  not  counted  here. 

B.  PARTITIONED  DATABASE  MODEL 

In  this  section  we  explain  the  partitioned  database  model  in  a  general  computer 
network;  modeling  of  the  partitioned  hierarchical  database  will  be  described  in  next  sec¬ 
tion. 

In  a  partitioned  distributed  database,  which  means  a  partially  replicated  database, 
items  are  not  replicated  at  all  nodes.  As  matter  of  fact,  some  items  might  not  be  dupli¬ 
cated  at  all.  There  might  exist  only  a  single  copy  of  some  items.  From  the  point  of  view 
of  a  single  node,  it  has  a  fraction  or  partition  of  the  database.  This  partition  can  be 
identical  to.  completely  disjointed  from,  or  can  overlap  the  partitions  at  other  nodes. 

In  order  to  model  the  partitioned  database,  we  choose  the  simple  model  (a  this  time 
it  is  not  a  hierarchical  model)  in  which  the  data  is  replicated.  As  we  mentioned  before, 
the  database  is  the  fixed  set  of  M  shared  named  resources  called  items.  Each  item  has  a 
name  and  some  value  associated  with  it.  For  simplicity,  we  use  the  integer  between  1  and 
M  { i.e.,  1  <  i  <  M). 

1.  DESCRIPTION  PARAMETERS 

Now  we  make  some  description  parameters  in  order  to  describe  the  model.  The 
set  S(i)  is  the  set  of  nodes  which  have  a  copy  of  the  value  of  item  i.  The  elements  of  S(i) 


arc  the  node  identification  numbers  which  have  a  copy  of  value  of  item  i.  We  assume 
all  sets  S(i)  are  not  empty.  Another  parameter  is  a  fragment,  which  is  defined  as  the  set 
of  items  that  have  a  same  set  S(i).  We  use  the  notation  S(F)  for  the  set  of  nodes  where 
the  F  is  stored.  That  is  S(F)  equals  S(i)  for  all  items  i  in  F.  These  parameters  are  used 
lor  simulation.  Figure  3  illustrates  the  very  simple  model  and  model  description  pa¬ 
rameters  for  current  control. 

I.et  Trl  be  the  transaction  which  arrives  at  node  B  and  has  the  base  set 

Bsl  =  i  1.  2.  3  ).  then 
S(l)  =  [  A.  B.  C.  Dj 
Si. 2)  =  1  A.  B.  C  1 
Si?)  =  [  A.  B.  C,  D) 

For  Trl  F  =  [  1.  3  ]  and  S(F)  =  [  A,  B.  C,  D  ]. 

L.et  Tr2  be  the  transaction  which  arrive  at  node  D.  and  has  the  base  set 
Bs2  =  [  3.  5  ],  then 
St  3)  =  [  A,  B.  C.  D  ] 

S(5)  =  [  A,  C,  D.  F  ] 

For  Tr2.  F  is  null  and  S(F)  is  not  defined. 

2.  DIRECTORY  MANAGEMENT 

Now  we  discuss  the  directory  management.  Suppose  that  a  transaction  arrives 
at  a  certain  node  with  its  base  set.  How  docs  the  transaction  know  what  nodes  have  a 
copy  of  data  item  i?  In  the  case  of  Trl,  which  we  used  in  the  previous  example,  how  does 
Trl  or  node  B  generate  the  set  S(i)? 

There  are  basically  two  kinds  of  solutions.  The  first  method  is  that  a  complete 
directory  of  the  whole  database  is  replicated  in  each  node.  The  other  method  is  that  the 
transaction  broadcasts  the  message  "  Where  is  the  item  i  located  ?  "  to  all  nodes  and 
waits  for  the  response  from  other  nodes  which  have  the  data  item  i  [Ref.  I  ].  A  directory 
is  a  mapping  that  produces  the  set  S(i)  or  S(F),  given  the  item  name  i  or  fragment  F. 
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By  consulting  the  director)',  a  transaction  T  will  be  able  to  find  out  the  set  S(i)  corre¬ 
sponding  to  ever)’  item  in  Bs.  In  next  chapter  we  take  care  of  this  problem  in  detail. 

C.  PARTITIONED  HIERARCHICAL  DATABASE  MODEL 

In  the  previous  section  we  described  the  general  model  of  a  partitioned  database. 
Now  we  will  make  a  hierarchical  model  of  the  partitioned  database.  When  we  describe 
the  hierarchical  computer  network,  the  level  will  be  important  factor.  The  level  is  the 
depth  of  the  network  from  the  root  node,  which  is  the  central  node  of  the  network  to  the 
bottom  nodes. 

One  of  the  characteristics  of  hierarchical  distributed  system  is  that  each  node  has  the 
authority  to  control  a  subordinate  node.  We  make  one  definition  here.  The  logical 
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control  channel  is  the  chain  of  control  which  can  give  authority  lor  updating.  This  defi¬ 
nition  is  very  important  because  although  there  may  be  a  physical  connection  between 
children  nodes,  it  is  not  logical  control  channel. 

Additional  assumptions  are  adopted  for  the  hierarchical  model.  Let  DI  be  tiie  total 
set  of  data  items  in  the  database  at  node  "1"  and  suppose  node  "\"  has  two  subordinate 

nodes  "2“  and  "3",  and  their  total  set  of  data  items  in  their  database  are  D2  and  D3  then 
Dl  =  D2  +  D3  +  data  items  of  node  I  s  own. 

We  can  generalize  this.  If  node  1  has  n  children  nodes,  then 
D ,  =  >  Dj  ■+-  I  s  own  data  items 
Where  D,  are  children  node  of  D] 

So  the  root  node  which  is  the  central  node  in  hierarchical  model  lias  ill  the  data 
items  in  the  network.  Another  important  assumption  we  use  is  that  the  transaction  Tr 
can  only  request  the  update  data  items  in  its  original  node.  If  items  which  are  referenced 
by  a  certain  transaction  are  not  located  at  that  node,  then  the  transaction  is  a  wrong 
transaction.  This  is  quite  reasonable  in  a  hierarchical  distributed  database  model. 

The  directory  of  our  model  is  somewhat  like  our  database,  so  each  node  has  its  own 
directory  and  the  root  node  has  a  whole  directory  of  the  system,  figure  4  illustrates  the 
very  simple  model  of  a  partitioned  hierarchical  database  model.  Let  Tr  1  arrive  at  node 

C  with  baseset  Bsl  =  [l,2J.  then 
S[l]  =  (A.  B.  C| 

S{ 2J  =  [A.  B,  C  1 

and  F  =  [  1.  2  J,  so  S[F[  =  (  A,  B.  C  | 

Let  Tr2  arrive  at  node  B  with  baseset  Bs2  =  [  1,  5.  8  ),  then 

•  Sj  I]  =  [  A,  B,  r  ] 

•  S[5|  =  [  A.  B,  D  | 
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S[8)  -  [  A,  B  J 

and  F  is  empty,  therefore  S(F]  is  not  defined. 
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IV.  ANALYSIS  OF  SIMULATION  RESULTS 


Figure  5.  Effect  of  Interarrival  Time  on  Response  Time 

We  have  tried  numerous  system  settings  and  studied  the  sensitivity  of  each  param¬ 
eter  separately.  Important  system  parameters  are  the  response  time,  the  number  of  nodes 
in  the  network,  the  number  of  levels  in  the  network,  the  interarrival  rate  of  transactions, 
and  the  average  system-wide  traffic.  All  curves  in  this  chapter  are  plotted  by  connecting 
discrete  data  points  from  simulation  results. 

Figure  5  shows  the  effect  of  the  mean  interarrivai  time  on  the  mean  response  time. 
We  notice  that,  the  longer  the  interarrivai  time  (low  arrival  rate),  the  shorter  response 
time  in  both  algorithms,  but  CLA  outperforms  the  DVA. 
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Figure  6.  Effect  of  Transmission  Time  on  Response  Time 
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Figure  8.  Effect  of  Level  of  Network  on  Response  Time 


This  is  because  in  CLA  only  the  root  node  perform  decision  making.  However  depend¬ 
ing  on  the  level  of  the  network,  the  results  vary.(See  Figure  7,  Figure  9,  Figure  10,  and 
Figure  1 1). 

The  effect  of  transmission  time  on  the  response  time  of  transaction  is  shown  in 
Figure  6.  Both  algorithms  exhibit  the  same  behavior.  The  CLA  appears  more  sensitive 
to  the  transmission  time  than  the  DVA.  This  is  because  the  number  of  traffic  in  CLA  is 
much  higher  than  that  of  DVA  (See  Figures  12,  and  13).  Also  the  CLA  begins  to  suffer 
a  transmission  delay  when  T  reachs  0.16  sec.  When  transmission  time  is  low,  DVA  is 
penalized  by  the  coordination  time  among  participants,  while  CLA  is  penalized  for  the 
time  required  to  send  the  grant  signal  to  the  requesting  node  when  the  transmission  time 
is  above  a  certain  threshold  (0.16  in  Figure  6). 


17 


Figure  9.  Effect  of  Interarrival  Time  on  Response  Time  for  Case  I 


Figure  10.  Effect  of  Interarrival  Time  on  Response  Time  for  Case  II 
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Figure  1 1.  Effect  of  Interrival  Time  Response  Time  for  Case  III 

Figure  7  shows  the  effect  of  the  number  of  r  'dcs  on  response  time.  For  both  al¬ 
gorithms,  increasing  the  number  of  nodes  in  the  network  increases  the  response  time  in 
an  0(n2)  manner,  which  means  the  performance  of  system  is  degrading.  The  increase  in 
response  time  is  due  to  the  fact  that,  as  the  number  of  sites  increases,  the  overall  rate 
of  arrival  of  transactions  into  the  system  also  increases,  causing  additional  delays  on  the 
processing  of  transactions.  The  DVA  is  less  sensitive  to  the  number  of  nodes  in  the 
network  than  the  CLA.  Because  in  the  CLA,  when  number  of  nodes  gets  larger  a  heavier 
I  O  loau  u  present  at  the  central  node,  but  in  the  DVA  the  1  O  load  is  distributed 
among  the  sites. 
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Figure  12.  Effect  of  Number  of  Nodes  on  Average  Traffic 


Figure  13.  Effect  of  Level  of  Network  on  Average  Traffic 
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The  effect  of  the  level  of  the  network  on  the  response  time  is  depicted  in  Figure  S. 
This  result  shows  that  the  level  of  hierarchical  network,  given  the  same  number  of  nodes, 
has  a  direct  impact  on  the  response  time.  The  impact  is  not  entirely  linear.  It  indicates 
a  tendency  that  the  performance  will  be  degraded  exponentially.  This  graph  is  somewhat 
complicated,  so  we  consider  3  cases  depending  on  the  level  of  network,  and  investigate 
the  response  time  versus  interarrival  time  for  each  case.  The  results  of  these  are  shown 
Figure  9.  Figure  10.  and  Figure  11.  Figure  9  shows  the  effect  of  interarrival  time  on  re¬ 
sponse  time  when  L  is  small  (i.e..  L  <  3).  T  he  CLA  performs  better  than  the  DVA  in 
this  case.  This  is  quite  reasonable  because,  when  L  is  small,  the  traffic  of  the  system  is 
not  as  important  a  factor  from  a  performance  point  of  view.  Thus,  the  CLA  takes  less 
tune  to  perform  the  transaction  than  the  DVA.  DVA  needs  extra  I  O  time  for  time¬ 
stamp  for  S[F].  Figure  10  shows  case  II  (i.e.,  3  <  L  <  15).  In  this  case,  the  DVA  per¬ 
forms  better  than  the  CLA,  because  if  L  gets  larger,  the  trallic  for  system  becomes  more 
important  and.  for  conflict  transaction,  the  transaction  has  to  get  to  the  central  node  in 
order  to  have  locks  in  CLA.  However,  for  DVA  the  transaction  will  be  rejected  before 
getting  to  the  central  node.  This  behavior  saves  much  of  the  DVA  s  response  time. 
Figure  11  shows  an  extreme  case  (i.e..  L  >  15).  In  this  case  the  two  algorithms  are  al¬ 
most  identical  in  performance. 

Figure  12  shows  the  average  trallic  versus  the  number  of  nodes  in  the  network.  For 
a  given  level  of  the  network,  the  average  traffic  of  the  system  is  increased  sharply  when 
number  of  nodes  get  to  10.  and  it  will  be  saturated  after  the  number  of  nodes  exceeds 
10. 

Figure  13  shows  the  average  traffic  of  the  network  versus  the  level  of  the  network. 
Here  we  observe  that  the  increasing  traffic  is  somewhat  linear,  but,  when  1.  gets  larger. 


the  rate  of  increase  is  decreased.  liven  though  figure  12  and  Figure  13  are  similar,  we 
can  sav  that  the  more  critical  factor  for  traffic  of  network  is  the  level  of  the  network. 


V.  CONCLUSION 


We  have  presented  a  performance  comparison  of  concurrency  control  algorithms. 
Based  on  the  results  obtained,  we  reached  the  following  major  co  iclusions: 

The  network  structure  is  the  most  important  factor  for  the  performance  of  concur¬ 
rency  control  algorithms.  Especially,  in  a  hierarchical  computer  network  the  level  of 
network  is  the  most  critical  factor  to  determine  the  performance  of'  concurrency  control 
algorithms. 

Although  we  discuss  each  parameter  individually,  a  network  designer  should  note 
that  all  of  them  are  related  and  should  consider  their  combined  effects  on  the  network 
performance.  1  he  tradeoffs  among  different  parameters  may  be  affected  by  other  oper¬ 
ational  policy  that  exists  in  the  system.  To  have  each  node  exhibiting  various  transaction 
rates  and  interarrival  rates  is  one  of  the  areas  that  needs  future  investigation  when  a 
network  designer  wants  to  customize  or  condition  the  network  to  his  need. 

This  study  was  the  first  trial  considering  the  hierarchical  structure  of  a  network  in 
performance  analysis  of  the  concurrency  control  area.  During  simulation  of  various  hi¬ 
erarchical  computer  networks  we  find  that  it  is  hard  to  describe  the  network  structure 
precisely,  for  example,  even  though  a  network  has  the  same  number  of  levels  and  same 
number  of  nodes,  there  arc  still  many  possible  system  configurations.  There  is  a  need 
for  a  better  network  representation  in  terms  of  data  structure  and  computation  algo¬ 
rithms. 

In  order  to  maximize  the  performance  of  the  network  the  choice  of  concurrency 
control  algorithms  is  very  important.  Since  the  network  structure  may  be  changed  dy¬ 
namically  so  we  may  need  to  develop  dynamic  concurrency  algorithms  which  can  per¬ 
form  best  under  various  svstem  structures. 
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APPENDIX  A.  SIMULATION  PROGRAM  LIST  TOR  CLA 


'  1  Vr  "jV  iV  tWt  Vr  -ViV  Vc  “V  -V  ~.’r  VnV  Vt  i'r  '.V  it -V  Vr  -.V  ■A-iV  iV  VrVr  -sWn’r  'V  'V  '.V  'V  -;'nV ViV  ~ V  ■; Wr  ~'r  tc  -;V 

''  This  program  is  written  for  simulation  of  CLA 

!  '  Vr'.WtVrjViVr'r-.VVrVr'^'iV^'sWrjV-.VVrVoVVfV'Vc'sVTV-VVrrtrVrVr^nV'V'jViVTV’s'rVr^WrVryrsVVr'WfTV' 


'  1  Vr  :'r  -V  -V  tc  :’r  iV  -,V  tV  :V  i Wr  Vr  it  ,V  Vr  i*  it  Vr  it  yp  it  Vr  iV  '.V  tt  yr  -,r  vr  tt  rr  yr  t:  Vt  tt  y-  Vr  yr  r  Yr  '.V  '.’ci’ri'trir 

PREAMBLE 

1  1  Vr  ;r  VrVrVr  :V  Vr  Vc  VcvWrVrVcVr  Vr^VVrVr-VVr  Vc:V‘V  Vr:V-,r  :T:V:Wr:WcyrVr''- V-yrV'yr'V  r-^rT’f 


NORMALLY,  MODE  IS  INTEGER 

DEFINE  RESPONSE.  TIME  TO  MEAN  ATRB1 
DEFINE  AVERAGE.  BASESET  TO  MEAN  ATRB2 
DEFINE  COMM. TRAFFIC  TO  MEAN  ATRB3 

EVENT  NOTICES  INCLUDE  TRANSACTION.  GEN ,  ARRIVAL.  AT. CENTRAL, 

RELEASE.  LOCK ,  UPDATE 

EVERY  ARRIVAL. AT.  CENTRAL  HAS  A  RECEIVE.  TRANSACTION 
EVERY  RELEASE. LOCK  HAS  A  DONE.  TRANSACTION 
EVERY  UPDATE  HAS  A  UPDATE.  TRANSACTION 

TEMPORARY  ENTITIES 

EVERY  TRANSACTION  HAS  A  GEN.  TIME,  A  TRANSACTION.  SEQ ,  A  MESSAGE.  TYPE , 
A  NODE.  NUM,  A  NODE.  LEVEL,  A  NUM.  OF.  BASESET,  A  BASE.  ITEM 
EVERY  TRANSACTION  MAY  BELONG  TO  THE  QUEUE 1, 

AND  MAY  BELONG  TO  THE  WAIT. QUEUE 

THE  SYSTEM  OWNS  THE  QUEUE  1,  THE  WAIT.  QUEUE 

DEFINE  QUEUE!  AS  A  FIFO  SET 

DEFINE  WAIT. QUEUE  AS  A  FIFO  SET 

DEFINE  INITIATE  AS  A  ROUTINE 

DEFINE  CHECK. LOCK  AS  A  ROUTINE 

DEFINE  REPORT.  GENERATOR  AS  A  ROUTINE 

DEFINE  TEST  AS  A  ROUTINE 

DEFINE  LOCK. LIST  AS  AN  INTEGER,  1-DIMENSIONAL  ARRAY 
DEFINE  BASE.  TABLE  AS  AN  INTEGER,  2 -DIMENSIONAL  ARRAY 

DEFINE  GEN. TIME,  RESPONSE. TIME ,  AVERAGE. BASESET,  T,  Cu,  Id,  Cs, 

COMM. TRAFFIC,  RATE  AS  A  REAL  VARIABLES 
DEFINE  TRANSACTION. NUM,  TRANSACTION.  SEQ,  MESSAGE.  TYPE ,  NODE.  NUM, 

NODE.  LEVEL,  NUM. OF. BASESET ,  QUE. INDEX,  LASTNODE, 

MINBASE,  MAXBASE ,  LOCK.  STATUS ,  Dn,  LIMITofTRANS ,  MAXLEVEL, 
BASE.  ITEM,  COUNT,  SYSTEM.  STATUS  AS  A  INTEGER  VARIABLES 

TALLY  AVE. RESPONSE  AS  THE  AVERAGE  OF  RESPONSE.  TIME 
TALLY  AVE.  TRAFFIC  AS  THE  AVERAGE  OF  COMM. TRAFFIC 

END 
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MAIN 

t  t  ... , 


iV'jWnWnWcVrVcVc'.Wr-jV-.VVf^WoWr'sWcVrjWcVfVr’iWc'VVfjWrVfVc'jViWr'jWr'jV 


RESERVE  BASE.  TABLE(*,*)  AS  2000  BY  5 
RESERVE  LOCK.  LIST  AS  2000 


READ 

SYS  RATE 

RATE 

=  SYS  RATE/ 20 

SCHEDULE  A  TRANSACTION. 

GEN  NOW 

LET 

T  =  0.  03  ' 

1 

MESSAGE  TRANSMISSION  TIME 

LET 

Cu  =  0. 001 

f 

CPU  TIME  SLICE  TO  COMPUTE  ACTUAL  VALUE  OF  TRANS 

LET 

Cs  =  0.  00001  ' 

1 

CPU  TIMESLICE  FOR  SMALL  COMPUTATION 

LET 

Id  =  0. 025  ' 

1 

I/O  TIME  SLICE  TO  READ  OR  WRITE  FROM  DATABASE 

LET 

LASTNODE  =  20 

1 

LAST  NODE  NUMBER 

LET 

MINBASE  =  1 

t 

MINIMUM  NUMBER  OF  BASESET 

LET 

MAX BASE  =  5  ' 

t 

MAXIMUM  NUMBEROF  BASESET 

LET 

CUE.  INDEX  =  0 

» 

QUE INDEX 

LET 

LOCK.  STATUS  =  0  ’ 

» 

IF  LOCKED  ALREADY  THEN  1  ELSE  0 

LET 

Du  =  1000  *  LASTNODE 

' '  TOTAL  DATA  ITEM  IN  THE  DATABASE 

LET 

LIMITofTRANS  =1000 

'  ’  THE  NUMBER  OF  TRANSACTION  SI.MMULATED 

-  r  T1 

Lj  Lj  1 

MAX LEVEL  =  3 

f 

LEVEL  OF  NETWORK 

LE  i 

COUNT  =  0 

NUMBER  OF  TRANSACTION 

LET 

TRANSACTION. NUM  = 

0 

LET 

SYSTEM. STATUS  =  0 

START 

END 


SIMULATION 


1  '  Vc-.VVfiV-.'r-.'nV-.'f.VVr-.'rVrVf-.WfiW."'.— .Vi'nV^V-.WrjWriVi'fiV-.WciWriWr-Wc-.V-.WTi'c-.ViVVr-.V-.WnV 

EVENT  TRANSACTION.  GEN 


CREATE  A  TRANSACTION 
ADD  1  TO  TRANSACTION.  NUM 
IF  TRANSACTION.  NUM  IS  GE  LIMITofTRANS 
CALL  REPORT.  GENERATOR 
ALWAYS 

LET  GEN. TIME  =  TIME.  V 
LET  MESSAGE. TYPE  =  1 
CALL  INITIATE 
IF  NODE. NUM  =  1 

IF  SYSTEM.  STATUS  =  0 
CALL  CHECK. LOCK 
ELSE 

FILE  TRANSACTION  IN  THE  WAIT. QUEUE 
REGARDLESS 

ELSE 

SCHEDULE  AN  ARRIVAL.  AT.  CENTRAL  GIVEN  TRANSACTION 
IN  (T  *  (NODE.  LEVEL  -  1  ))  MINUTES 
REGARDLESS 

SCHEDULE  A  TRANSACTION.  GEN  IN  ( EXPONENTIAL. F( RATE , 1) )  MINUTES 

RETURN 

END 


25 


'  '  it  it  -V  ''r'V-iWr'WcVr  ',V  :V  -V 'V * -r  *  iV  Vr  Vn'n'n1: 'V  ',v  Vr  * 'V  ~.V  Vc  -,’r  *Vc  Vr  it  it  it  -,V 'V  iV  "V  it  it  it  it  it  it  it 


ROUTINE  INITIATE 

!  1  it  it  '.V  it  it  it  it  it  it  i:  it  it  it  it  it 


•it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it 


ADD  1  TO  TRANSACTION. SEQ 

NODE. NUM  =  TRUNC. F( UNIFORM.  F( 1 , LASTNODE , 1) ) 

IF  NODE. NUM  =  1  NODE.  LEVEL  =  1 
ELSE 

IF  NODE. NUM  =  2  OR  NODE. NUM  =  3  NODE.  LEVEL  =  2 
ELSE 

NODE. LEVEL  =  3 
REGARDLESS 
REGARDLESS 

NUM.  OF.  BASESET  =  TRUNC.  F( UNIFORM. F(MINBASE .MAXBASE , 1) ) 

LET  J  =  TRANSACTION.  SEQ 

FOR  I  =  1  TO  NUM. OF. BASESET 
DO 

IF  NODE. NUM  =  1  BASE.  TABLE( J , I )  =  TRUNC. F( UNIFORM. F(  1 , 2000 , 1 ) ) 
ALWAYS 

IF  NODE. NUM  =  2  BASE.  TABLE( J , I )  =  TRUNC. F( UNIFORM. F(  1 ,900, 1) ) 


ALWAYS 

IF  NODE. NUM  =  3  BASE. TABLE( J , I )  =  TRUNC. F( UNIFORM.  F( 90 1 , 1900 , 1 ) ) 
ALWAYS 

IF  NODE. NUM  >  3  AND  NODE. NUM  <  12 

BASE. TABLE( J , I )  =  TRUNC. FCUNIFORM. F( 1 , 800 , 1 ) ) 


ALWAYS 

IF  NODE.  NUM  >  11  BASE.  TABLE(  J ,  I )  =  TRUNC.  F(  UNIFORM.  F(  90 1 , 1800 , 1 ) ) 
ALWAYS 
LOOP 
END 


1  1  it  it  it  it  it  it  it  it  it  it  it  '.V  it  it  txit  it  it  it  Vr  Vr  'V  it  Vr  it  it  it  if  it  it  it  it  it  it  it  -V  it  it  it  it  it  it  it  it  it  it  it 

EVENT  ARRIVAL. AT. CENTRAL  GIVEN  RECEIVE. TRANSACTION 

1  1  it  it  i tit  it  it  it  it  it  it  it  it  Vc  it  it  it  it  it  ',V  it  Vr  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  it  'it  it  it  it 


IF  MESSAGE. TYPE( RECEIVE. TRANSACTION)  =  1 

IF  SYSTEM. STATUS  =  0 

SYSTEM.  STATUS  =  1 
CALL  CHECK. LOCK 

ELSE 

FILE  RECEIVE. TRANSACTION  IN  THE  WAIT.  QUEUE 
REGARDLESS 

ELSE  SCHEDULE  A  RELEASE. LOCK  GIVEN  RECEIVE. TRANSACTION 

IN  (  T  *  (NODE. LEVEL( RECEIVE. TRANSACTION) -1))  MINUTES 
REGARDLESS 
RETURN 
END 


'  '  ->"'r 'V -.V  -'r-‘c~'r'V  \  7 '.Y'.-'V  “’r  Tr'V  'V'V  Yr'Wr  Yr'Y'rVrTY'.c":';'  'V'V'V'V'r  Vr ''"'r-YYr'r'Wr  Vr-Y  ~.Y-;Y  Vr 

ROUTINE  CHECK. LOCK 


LET  LOCK. STATUS  =  0 

FOR  I  =  1  TO  NUM. OF. BASESET 

DO 

IF  LOCK. LIST( BASE. TABLEC TRANSACTION. SEQ, I))  =  1 
LOCK.  STATUS  =  1 
ALWAYS 
LOOP 

IF  LOCK. STATUS  =  1  FILE  TRANSACTION  IN  THE  QUEUE  1 

QUE. INDEX  =  QUE. INDEX  +  1 

ELSE 

FOR  I  =  1  TO  NUM. OF.  BASESET 
DO 

LOCK.  LIST  (BASE. TABLE! TRANSACTION.  SEQ, I))  =  1 
LOOP 

SCHEDULE  AN  UPDATE  GIVEN  TRANSACTION- 
IN  (T  (NODE.  LEVEL  -1))  MINUTES 
REGARDLESS 


END 


EVENT  UPDATE  GIVEN  UPDATE.  TRANSACTION 


MESSAGE.  TYPE( UPDATE.  TRANSACTION)  =  2 

SCHEDULE  AN  ARRIVAL.  AT.  CENTRAL  GIVEN  UPDATE. TRANSACTION  IN 
! NUM.  OF. BASESET! UPDATE. TRANSACTION) 

*  (Cu  +  2* Id)  +( (NODE. LEVEL! UPDATE. TRANSACTION) -1J  *  T) )  MINUTES 


RETURN- 

END 


EVENT  RELEASE. LOCK  GIVEN  DONE. TRANSACTION 


FOR  I  =  1  TO  NUM. OF. BASESET! DONE. TRANSACTION) 

DO 

LOCK. LIST  (BASE. TABLE! TRANSACTION. SEQ! DONE. TRANSACTION) ,1))  =  0 
LOOP 

LOCK. STATUS  =  0 

LET  RESPONSE.  TIME  =  TIME.  V  -  GEN.  TIME! DONE. TRANSACTION) 

LET  COMM. TRAFFIC  =  NODE.  LEVEL! DONE. TRANSACTION)  *  3 
LET  AVERAGE.  BASESET  =  NUM. OF. BASESET 
SYSTEM. STATUS  =  0 

IF  QUEUE 1  IS  NOT  EMPTY 

REMOVE  THE  FIRST  TRANSACTION  FROM  THE  QUEUE  1 
QUE. INDEX  =  QUE. INDEX  -  1 
SYSTEM.  STATUS  =  1 
CALL  CHECK. LOCK 

ELSE 
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IF  WAIT.  QUEUE  IS  NOT  EMPTY 

REMOVE  THE  FIRST  TRANSACTION  FROM  THE  WAIT.  QUEUE 
SYSTEM. STATUS  =  I 
CALL  CHECK. LOCK 

ALWAYS 

REGARDLESS 

RETURN 

END 

1  1  V:  V:  V:  Vr  'V  -V  Vr  -.V  Vr  -V  'V  ~V'V  'V  '.V  Vr -V  Vr  Vr  vr  i'c  Vr  Vr  -V  -ic  ’V  Wr  Vr  'V  'V  Vc  -.V  Vr  Vr  'V  Vc  V:  V?  Vt  V?  V?  rr  ~'r  ~'r 

ROUTINE  REPORT. GENERATOR 

1  1  *  V  'V  Vr  'V  ~'r  ir  “V  ~V  'V  ‘.V  Yc  'V  VrYr  Vor  Yr  -V  '.V  Yr  Yr  Yr  iY  Yt  Yr  YoY  Yr  Yr  Yr  Yr  'V  Yr  Yc  Yr  Yc  '.V  '.V  Yr  Yr Yr  -/r  -.V  Yr  Yr  Yr  Yr 


SKIP  2  OUTPUT  LINES 
PRINT  1  LINE  THUS 

STIMULATION  RESULT  OF  TWO  PHASE  LOCKING  ALGORITHM 
SKIP  1  LINE 
PRINT  2  LINE  THUS 

I.  MODEL  INPUT  PARAMETER 

a.  MODEL  DESCRIPTION 

PRINT  3  LINE  WITH  MAXLEVEI.,  LASTNODE,  AND  Dn  THUS 

1.  LEVEL  OF  THE  NETWORK: 

2.  NUMBER  OF  NODE  IN  NETWORK: 

3.  DATA  ITEMS  IN  NETWORK:  **** 

PRINT  1  LINE  THUS 

b.  STIMULATION  PARAMETERS 

PRINT  3  LINE  WITH  LIMITofTRANS ,  RATE,  AND  MAX BASE  THUS 

1.  NUMBER  OF  TRANSACTION  STIMULATED  :  **** 

2.  MEAN  INTERARRIVAL  TIME  :  *.* 

3.  MAXIMUM  BASESET  : 

PRINT  I  LINE  THUS 

II.  RESULTS  OF  S IMMOLATION 

PRINT  2  LINE  WITH  AVE. RESPONSE*HOURS.  V*MINUTES.  V , 

AVE. TRAFFIC  THUS 

a.  THE  AVERAGE  RESPONSE  TIME  OF  UPDATE  TRANSACTION  :  * 

b.  THE  AVERAGE  NUMBER  OF  TRAFFIC  : 

STOP 

END 


2S 


APPENDIX  B.  SIMULATION  PROGRAM  LIST  FOR  DVA 


PREAMBLE 


■'jVVr-jVVt’VrVrVrVcVcVrs’rjV'jWoWoWfVc’Vr'jV' 


NORMALLY,  MODE  IS  INTEGER 

DEFINE  RESPONSE. TIME  TO  MEAN  ATRB1 
DEFINE  AVERAGE. BASESET  TO  MEAN  ATRB2 
DEFINE  COMM. TRAFFIC  TO  MEAN  ATRB3 

EVENT  NOTICES  INCLUDE  TRANSACTION. GEN ,  VOTING, 

CHSCK_QK 

EVERY  VOTING  HAS  A  VOTING. TRANSACTION 
EVERY  CHECK  OK  HAS  A  CHECKING. TRANSACTION 


TEMPORARY  ENTITIES 

EVERY  TRANSACTION  HA?  /  GEN. TIME ,  A  TRANSACTION. SEQ ,  A  MESSAGE. TYPE , 
A  NODE. No  '  A  NODE.  LEVEL,  A  NUM. OF. BASESET ,  A  BASE.  ITEM, 

A  TIMr  '  RIP ,  A  CUKRENT_NODE 
EVERY  TRANSACTION'  ,'jAY  BELONG  TO  THE  QUEUE  1, 

AND  MAY  BELONG  TO  THE  WAIT.  QUEUE 

THE  SYSTEM  OWNS  THE  QUEUE  1,  THE  WAIT, QUEUE 

DEFINE  QUEUE  1  AS  A  FIFO  SET 

DEFINE  WAIT. QUEUE  AS  A  FIFO  SET 

DEFINE  INITIATE  AS  A  ROUTINE 

DEFINE  INPUTRTN  AS  A  ROUTINE 

DEFINE  FINDSET  AS  A  ROUTINE 

DEFINE  INITIAL.TAB  AS  A  ROUTINE 

DEFINE  SEND_ACCEPT  AS  A  ROUTINE 

DEFINE  SEND_REJECT  AS  A  ROUTINE 

DEFINE  SYSTEM.CONTROL  AS  A  ROUTINE 

DEFINE  EN  QUEUE  AS  A  ROUTINE 

DEFINE  REPORT.  GENERATOR  AS  A  ROUTINE 

DEFINE  CHILDREN_TAB  AS  AN  INTEGER,  2-DIMENSIONAL  ARRAY 
DEFINE  PARENT_TAB  AS  AN  INTEGER,  1 -DIMENSIONAL  ARRAY 
DEFINE  DATA_DIR  AS  AN  INTEGER,  2-DIMENSIONAL  ARRAY 
DEFINE  LEVEL_TAB  AS  AN  INTEGER,  1-DIMENSIONAL  ARRAY 
DEFINE  BASE. TABLE  AS  AN  INTEGER,  2-DIMENSIONAL  ARRAY 
DEFINE  SET_TAB  AS  AN  INTEGER,  2-DIMENSIONAL  ARRAY 
DEFINE  TSofDB  AS  A  REAL,  2-DIMENSIONAL  ARRAY 
DEFINE  STATUS_TAB  AS  AN  INTEGER,  1 -DIMENSIONAL  ARRAY 


DEFINE  GEN. TIME,  RESPONSE. TIME ,  AVERAGE. BASESET,  T,  Cu ,  Id,  Cs , 
COMM. TRAFFIC,  TIME_STAMP , RATE  AS  A  REAL  VARIABLES 
DEFINE  TRANSACTION. NUM,  TRANSACTION. SEQ,  MESSAGE. TYPE ,  NODE. NUM, 
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NODE. LEVEL,  NUM. OF. BASESET ,  QUE.  INDEX,  LASTNODE ,CURRENT_NODE , 
MINBASE,  MAXBASE ,  LOCK.  STATUS,  Dn,  LIMITofTRANS ,  MAXLEVEL, 
BASE.  ITEM,  COUNT,  SYSTEM.  STATUS ,  YESN'O  AS  A  INTEGER  VARIABLES 
DEFINE  MAX_PATH  AS  AN  INTEGER  VARIABLE 

TALLY  AVE. RESPONSE  AS  THE  AVERAGE  OF  RESPONSE.  TIME 
TALLY  AVE.  BASESET  AS  THE  AVERAGE  OF  AVERAGE.  BASESET 
TALLY  AVE. TRAFFIC  AS  THE  AVERAGE  OF  COMM. TRAFFIC 

END 


' ' ************************************************ 
MAIN 

’  1  ************************************************ 


CALL  INITIAL.TAB 
PRINT  1  LINE  THUS 

DO  YOU  WANT  DEFAULT  MODEL  ?  IF  YES  TYPE  1 
READ  YESN'O 

IF  YESN'O  <>  1 
CALL  INPUT_RTN 
ALWAYS 


SCHEDULE  A  TRANSACTION. GEN  NOW 


LET  T  =  0.  2 

LET  Cu  =  0. 001 

LET  Cs  =  0. 00001 

LET  Id  =  0. 025 

LET  LASTNODE  =10 

LET  MINBASE  =1 

LET  MAXBASE  =5 

LET  QUE. INDEX  =0 

LET  LOCK. STATUS  =  0  1  ' 

LET  Dn  =  1000 

LET  LIMITofTRANS  =1000 

LET  MAXLEVEL  =3 

LET  COUNT  =0  " 

LET  TRANSACTION. NUM  =  0 

LET  SYSTEM. STATUS  =  0 

LET  RATE  =  3 

START  SIMULATION 

END 


MESSAGE  TRANSMISSION  TIME 

CPU  TIME  SLICE  TO  COMPUTE  ACTUAL  VALUE  OF  TRANS 

CPU  TIMESLICE  FOR  SMALL  COMPUTATION 

I/O  TIME  SLICE  TO  READ  OR  WRITE  FROM  DATABASE 

LAST  NODE  NUMBER 

MINIMUM  NUMBER  OF  BASESET 

MAXIMUM  NUMBEROF  BASESET 

QUE INDEX 

IF  LOCKED  ALREADY  THEN  1  ELSE  0 
TOTAL  DATA  ITEM  IN  THE  DATABASE 
"  THE  NUMBER  OF  TRANSACTION  S IMMOLATED 
LEVEL  OF  NETWORK 
NUMBER  OF  TRANSACTION 


' ' ************************************************ 
EVENT  TRANSACTION. GEN 

' ' ************************************************ 


CREATE  A  TRANSACTION 
ADD  1  TO  TRANSACTION.  NUM 
LET  TRANSACTION. SEQ  =  TRANSACTION. NUM 
IF  TRANSACTION.  NUM  IS  GE  LIMITofTRANS 
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CALL  REPORT. GENERATOR 
ALWAYS 

LET  GEN. TIME  =  TIME.  V 
LET  TIME_STAMP  =  TIME.  V 
CALL  INITIATE 
CALL  FIND  SET 


SCHEDULE  A  TRANSACTION. GEN  IN  (EXPONENTIAL. F( RATE , 1) )  MINUTES 
RETURN 

END 


ROUTINE  INITIAL_TAB 


RESERVE  C H I LD R E N_T A B ( *,* )  AS  30  BY  30 

RESERVE  PARENT_TAB ,  LEVEL_TA3 ,  STATUS_TAB  AS  30 

RESERVE  DATA  D IRC  * ,*)  AS  30  BY  2 

RESERVE  BASE.  TABLE(*,*}  AS  1000  BY  5 

RESERVE  S ET_TAB ( * , * )  AS  5  BY  30 

RESERVE  TSofDB (•■-,•'■)  AS  30  BY  1000 

FOR  I  =  1  TO  1000 
DO 

FOR  J  =  1  TO  5 
DO 

BASE. TABLE( I , J)  =  0 

LOOP 

LOOP 

FOR  I  =  1  TO  30 
DO 

PARENT_TAB( I)  =  0 
LEVEL_TAB( I )  =  0 
STATUS_TAB( I)  =  1 
FOR  J  =  1  TO  30 
DO 

CHILDREN_TAB( I , J)  =  0 

LOOP 

FOR  J  =  1  TO  2 
DO 

DATA_DIR( I , J)  =  0 

LOOP 

FOR  J  =  1  TO  1000 
DO 

TSofDB(I.J)  =  0. 0 

LOOP 

LOOP 

FOR  I  =  1  TO  5 
DO 

FOR  J  =  1  TO  30 
DO 

SET_TAB( I , J)  =  0 
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LOOP 


LOOP 

RELEASE  CHILDRE\'_TAB ,  PARENT_TAB ,  DATA_DIR,  LEVEL_TAB ,  BASE.  TABLE, 
SET_TA3 ,  TSoFDB ,  STATUS_TAB 

END 


t  » 


ROUTINE  INITIATE 

f  1  iV  VrVc  Vr  Vr  Vr  Vr  *V  Vr  Vr  Vr  5V  Vr  Vf  Vc  Vr  Vr  Vr  Vr  Vr  Vc  Vc  Vr  Vc  Vr  Vr  *,V  Vc  Vr  Vc  Vc  Vc  Vr  *  “V  Vc  Vc  Vr  Vf  Vc  * 


■•/WcjVVrVr 


RESERVE  LEVEL_TAB  AS  30 
RESERVE  DATA_D I R( AS  30  BY  2 
RESERVE  BASE. TABLE(*,*)  AS  1000  BY  5 
ADD  1  TO  TRANSACTION. SEQ 

NODE. NUM  =  TRUNC.  F(  UNIFORM.  F( 1 , LASTNODE , 1 ) ) 

LET  CURRENT_NODE  =  NODE.  NUM 

IF  YF.SNO  =1  ’  '  *******  IF  DEFAULT  NETWORK  ****** 

IF  NODE. NUM  =  1  NODE.  LEVEL  =  1 
ELSE 

IF  NODE.  NUM  =  2  OR  NODE. NUM  =  3  OR  NODE. NUM  =  4  NODE. LEVEL  =  2 
ELSE 

NuDE.  LEVEL  =  3 
REGARDLESS 
REGARDLESS 


NUM.  OF.  BASESET  =  TRUNC.  F( UNIFORM. Ff MINBASE .MAXBASE , 1 ) ) 

LET  J  =  TRANSACTION. SEQ 

FOR  I  =  1  TO  NUM. OF. BASESET 

DO 

IF  NODE. NUM  =  1  BASE. TABLE! J , I )  =  TRUNC.  F( UNIFORM.  F( 00 1 , 1000 , 1) ) 
DATA_DIR( 1,1)  =  001 
DATA_DIR( 1,2)  =  1000 

ALWAYS 

IF  NODE.  NUM  =  2  BASE.  TABLE! J, I )  =  TRUNC. F( UNIFORM.  F( 00 1 , 400 , 1 ) ) 
DATA_DIR( 2,1)  =  001 
DATA  DIR( 2, 2)  =  400 

ALWAYS 

IF  NODE. NUM  =  3  BASE. TABLE! J , I )  =  TRUNC. F! UNIFORM. F! 40 1 , 700 , 1 ) ) 
DATA_DIR( 3,1)  =  401 
DATA_DIR! 3,1)  =  700 

ALWAYS 

IF  NODE. NUM  =  4  BASE.  TABLE! J , I )  =  TRUNC. F! UNIFORM. F( 701 ,900 , 1) ) 
DATA_DIR( 4,1)  =  701 
DATA_DIR( 4,2)  =  900 

ALWAYS 

IF  NODE. NUM  =  5  BASE. TABLE! J , I )  =  TRUNC. F( UNIFORM. F( 1 , 100 , 1 ) ) 
DATA_DIR! 5,1)  =  001 
DATA_DIR( 5,2)  =  100 

ALWAYS 

IF  NODE. NUM  =  6  BASE. TABLE! J , I )  =  TRUNC.  F! UNIFORM.  F!  10 1 , 200 , 1 ) ) 
DATA_DIR! 6,1)  =  101 
DATA_DIR( 6,2)  =  200 
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ALWAYS 

IF  NODE. NUM  =  7 

BASE.  TABLET J, I)  =  TRUNC.  FT  UNIFORM.  F( 20 1 , 300 , 1 ) ) 
DATA  DIR( 7,1)  =  201 

DATA_DIR( 7,2)  =  300 

ALWAYS 

IF  NODE. NUM  =  8 

BASE. TABLET J, I)  =  TRUNC. FT  UNIFORM.  F( 401 ,500, 1) ) 
DATA  DIRT  8,1)  =  401 

DATA_DIRC  8,2)  =  500 

ALWAYS 

IF  NODE. NUM  =  9 

BASE. TABLET J, I)  =  TRUNC.  FT  UNIFORM.  F(  50 1 , 600 , 1 ) ) 
DATA  DIRl.9,1)  =  501 

DATA_DIR( 9,2)  =  600 

ALWAYS 

IF  NODE.  NUM  =  10 

BASE. TABLET J, I)  =  TRUNC. F( UNIFORM.  F(  701 ,800 , 1) ) 
DATA  DIRT  10,1)  =  701 

DATA  DIRT  10,2)  =  800 

ALWAYS 

LOOP 

LET  LEVEL_TAE'l)  =  1 
FOR  I  =  2  TO  i 

TO 

LET  LEVEL_TAB( I '  =  2 

loop 

FOR  I  =  5  TO  10 
DO 

LET  LEVEL_TAB( I )  =  3 
LOOP 


ELSE  '  '  *******  xp  s’ot  DEFAULT  NETWORK  *************** 
NODE.  LEVEL  =  LEVEL_TAB(NODE. NUM) 

Nl'M.OF.  BASESET  =  TRUNC.  F( UNIFORM.  F(  MINBASE , MAXBASE  ,  1 ) ) 
LET  J  =  TRANSACTION. NUM 
FOR  I  =  1  TO  NUM. OF. BASESET 


* 


DO 


BASE. TABLET J, I)  =  TRUNC. F( UNIFORM. F( DATA_DIR( NODE.  NUM, I) , 

DATA_D IRC  NODE.  NUM, 2) , 1)) 

LOOP 

REGARDLESS 


END 


'  '  *********************************************** 
ROUTINE  INPUT_RTN 

f  1  *********************************************** 


RESERVE  CHI LCREN_TAB( * , * )  AS  30  BY  30 

RESERVE  LEVEL_TAB  AS  30 

RESERVE  DATA_D IRC  * , * )  AS  30  BY  2 

RESERVE  PARENT  TAB  AS  30 

LET  INDX  =  2 

PRINT  2  LINE  THUS 

INPUT  PARAMETERS  CAREFULLY  !  ! 

HOW  MANY  NODES  THE  NETWORK  HAVE  7  ' 
READ  LASTNODE 
PRINT  1  LINE  THUS 


WHAT  IS  THE  LEVEL  OF  THE  NETWORK  ? 

READ  MAX LEVEL 

FOR  I  =  1  TO  LASTNODE 

DO 

PRINT  1  LINE  WITH  I  THUS 

HOW  MANY  CHILDREN  DODES  NODE  **  HAVE  ? 

READ  J 
IF  J  <>  0 

FOR  K  =  1  TO  J 
DO 

IF  INDX  <=  LASTNODE 

CHILDREN_TAB( I ,K)  =  INDX 
PARENT_TAB( INDX)  =  I 
INDX  =  INDX  +  1 
ALWAYS 
LOOP 
ALWAYS 
LOOP 

FOR  J  =  I  TO  LASTNODE 

DO 

PRINT  1  LINE  WITH  J  THUS 

WHAT  IS  THE  LEVEL  OF  NODE  **  AND  RANGE  OF  DATA  ITEM  ? 
READ  L£YEL_TAB( J) ,  DATA_DIR( J , 1 ) ,  AND  DATA_DIR( J , 2 ) 
LOOP 


PRINT  1  LINE  THUS 

THANK  YOUR  INPUT  IS  DONE  !!! 


END 


ROUTINE  FIND_SET 


"  THIS  ROUTINE  GENERATE  SETS  WHICH  Ssi  AND  S°F 

RESERVE  LEVEL_TAB  AS  30 

RESERVE  SET_TAB(* ,*)  AS  5  BY  30 

LET  MAX.PATH  =  0 

FOR  I  =  1  TO  NUM. OF.  BASESET 

DO 

FOR  J  =  1  TO  LASTNODE 
DO 

IF  BASE. TABLE(TRANSACTION.  SEQ.I)  >=  DATA_DIR( J , 1 ) 
BASE. TABLE( TRANSACTION. SEQ, I)  <=  DATA_DIR( J , 2) 
SET  TAB(I.J)  =  1 
ALWAYS 
LOOP 

LOOP 

FOR  I  =  1  TO  LASTNODE 
DO 

LET  BASE_COUNT  =  0 
LET  NODE  STATUS  =  0 


AND 
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FOR  J  =  1  TO  NUM. OF. BASESET 
DO 

IF  SET_TAB( J , I )  <>  0 

BASE_COUNT  =  BASE_COUNT  +  1 
NODE_STATUS  =  1 
ALWAYS 
LOOP 

IF  NODE_STATUS  =  1 

LET  CURRENTJsODE  =  I 

IF  MAX_PATH  <=  ABS.  F(LEVEL_TAB( NODE. NUM)  -  LEVEL_TAB( CURRENT  NODE)) 
MAX_PATH  =  ABS.  F(LEVEL_TAB( NODE. NUM)  -  LEVEL_TAB(CURRENT_NODE) ) 
ALWAYS 

PRINT  5  LINE  WITH  NODE. NUM,  CURRENT_NODE ,  LEVEL_TAB( NODE. NUM) , 
LEVEL_TAB(CURRENT_NOD£) ,  BASE_COUNT  THUS 
NODE. NUM  =  ** 

CURRENT_NODE  =  ** 

LEVEL  OF  NODE. NUM  =  ** 

LEVEL  OF  CURRENT  NODE  =  ** 

BASE  COUNT  = 

SCHEDULE  A  VOTING  GIVEN  TRANSACTION  IN 

(  (ABS. F( LEVEL  TABC NODE. NUM)  -  LEVEL_TAB( CURRENT_NODE) )  *  T)  + 

(BASE  COUNT  *  Id  ))  MINUTES 

ALWAYS 

LOOP 

SCHEDULE  A  CHECK  OK  GIVEN  TRANSACTION  IN  ( ( MAX_PATH  *  T)  +  NUM.  OF.  BASESET) 
MINUTES 


END 


1  1  Vr  Vr  *>V  *; V  V?  Vr  Vr  *>V  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  *  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr  Vr 

EVENT  VOTING  GIVEN  VOTING.  TRANSACTION 
1  1 


RESERVE  TSofDB(*,*)  AS  30  BY  1000 
RESERVE  STATUS_TAB  AS  30 
LET  OK  STATUS  =  0 

FOR  K  =  1  TO  NUM. OF. BASESET( VOTING.  TRANSACTION) 

DO 

IF  SET_TAB(K,CURRENT_NODE( VOTING.  TRANSACTION))  <>  0 
IF  TIME  STAMP( VOTING. TRANSACTION)  >=  TSofDB(CURRENT_NODE( VOTING.  TRANSACTION) , 
BASE.  TABLE( TRANSACTION.  SEQ( VOTING. TRANSACTION) ,K) 

OK_STATUS  =  1 
ALWAYS 
ALWAYS 
LOOP 

IF  OK_STATUS  =  1 

TIME_STAMP( VOTING.  TRANSACTION)  =  TIME. V 
STATUS_TAB(CURR£NT_NODE( VOTING.  TRANSACTION))  =  1 
ELSE 

STATUS_TAB( CURRENT_NODE( VOTING.  TRANSACTION) )  =0 
REGARDLESS 
RETURN 


END 


35 


1  '  lWfiWr-V'A-jVVr'i'riV-V-WrVrVr'jV-W-VnWrV— V*iW-******-Wf ************** 

ROUTINE  SEND_ACCEPT 

'  '  ;V;r:'rV,-VrVrVr:V-.V^V-V:>^V-V;VVr-V-'r'V:V'!V**5'r**5V***5V5V***VrVr3'r*Vr******-5Wf 

FOR  I  =  1  TO  LASTNODE 
DO 

FOR  J  =  1  TO  NUM. OF. BASESET( TRANSACTION) 

DO 

IF  SET_TAB( J, I )  =  1 

IF  TSofDB( I , J)  <=  TIME_STAMP( TRANS ACTION) 
TSofDB(I.J)  =  TIME_STAMPi.  TRANSACTION) 
ALWAYS 
ALWAYS 
LOOP 
LOOP 

LET  RESPONSE. TIME  =  TIME. V  -  GEN.  TIME (TRANS ACT I ON) 
FOR  I  =  1  TO  LASTNODE 
DO 

FOR  J  =  1  TO  NUM. OF. BASESET(TRANSACTION) 

DO 

SET_TAB( J , I )  =  0 

LOOP 

STATUS_TAB( I )  =  0 
LOOP 

CALL  SYSTEM_CONTROL 


END 


'  t  V* “W* Vr y* V? V» Vr VnW\ Vf V? Vf Vr VpV* V* V» V“Vr 

ROUTINE  SEND  REJECT 


^  ^  J#  J  #  J «  J-  Ja  J 


CALL  EN.OUEUE 

CALL  SYSTEM_CONTROL 

END 


ROUTINE  EN_QUEUE 

FILE  TRANSACTION  IN  THE  QUEUE 1 

' ' ALWAYS 

' '  ****  KEEP  CONTINUE 
END 

ROUTINE  SYSTEM_CONTROL 
IF  QUEUE  1  IS  NOT  EMPTY 

REMOVE  FIRST  TRANSACTION  FROM  THE  QUEUE 1 
CALL  FIND_SET 
ELSE 

SCHEDULE  TRANSACTION. GEN  NOW 
ALWAYS 
END 

'  '  ************************************************ 
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EVENT  CHECK_GK  GIVEN  CHECKING. TRANSACTION 


“Wf.Wr 


"sc  VrVv'Vr 


RESERVE  STATUS_TAB  AS  30 
ITS_OK  =  1 

FOR  I  =  1  TO  LASTNODE 
DO 

ITS_OK  =  ITS_OK  *  STATUS_TAB( I ) 

LOOP 

IF  ITS_QK  <>  1 

TIME_STAMP( CHECKING.  TRANSACTION)  =  TIME.  V 
CALL  SEND_ACCEPT 
ELSE 

CALL  SEND_REJECT 
REGARDLESS 
RETURN 
END 

1  1  '.V  'V  'V  ~ VVr  '.'r  :nr  'V  ■"/'  'V  'V  'V  VnV  -/r  iV  Vr  'V  Vr  'V  'V  Vr  'V  ‘V  'V  'V  :V  ~'r  Vr  ~'r  rr  Vr  iV  ~V  ~V  ~r  'V  “V  'V  “V 

ROUTINE  REPORT. GENERATOR 

1  T  Vr Vr V; Vr  :’r ‘r V; ,'r Vr -,’r -,'r V: V: 'V -,’c Vr ‘,V 'V rr -V Vr -V -,V -V Vr V,-  “V Vr Vr  'V  ~'r  ~.V V-Vr :V  Vr -.'r Vr Vr 'V 


SKIP  2  OUTPUT  LINES 
PRINT  I  LINE  THUS 

STIMULATION  RESULT  OF  TOO  PHASE  LOCKING  ALGORITHM 
SKIP  1  LINE 
PRINT  2  LINE  THUS 

I.  MODEL  INPUT  PARAMETER 

a.  MODEL  DESCRIPTION 

PRINT  3  LINE  WITH  MAXLEVEL,  LASTNODE,  AND  Dn  THUS 

1.  LEVEL  OF  THE  NETWORK:  ** 

2.  NUMBER  OF  NODE  IN  NETWORK: 

3.  DATA  ITEMS  IN  NETWORK:  **** 

PRINT  1  LINE  THUS 

b.  STIMULATION  PARAMETERS 

PRINT  3  LINE  WITH  LIMITofTRANS ,  RATE,  AND  MAXBASE  THUS 

1.  NUMBER  OF  TRANSACTION  STIMULATED  :  **** 

2.  MEAN  INTERARRIVAL  TIME  :  *.  * 

3.  MAXIMUM  BASESET  : 

PRINT  1  LINE  THUS 

II.  RESULTS  OF  STIMULATION 

PRINT  2  LINE  WITH  AVE.  RESPONSE’vHOURS.  V*MINUTES.  V,  MINBASE  THUS 

a.  THE  AVERAGE  RESPONSE  TIME  OF  UPDATE  TRANSACTION  :  **  * 

b.  THE  AVERAGE  NUMBER  OF  BASESET:  ** 

STOP 

END 
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